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CHAPTER  1 

Project  Overview 

Following  the  study  on  Permit  Procedures  for  Overweight  Trucks,'  a  quick  study  to 

determine  how  the  Michigan  Trains  permitting  process  should  be  automated  was  conducted.  The 
quick  study,  which  mainly  was  used  to  glue  [1]  to  an  implementation  utilizing  the  knowledge 
already  gained,  was  requested  by  INDOT  in  July  of  1995.  During  the  execution  of  this  study,  it 
was  determined  that  the  Indiana  Governor  had  ordered  the  creation  of  a  "one-stop  shop"  to 
service  all  truck  permitting  &  licensing  needs.  This  "one-stop  shop"  ultimately  would  need  to 
reside  within  the  Indiana  Department  of  Revenue  (EDR)  instead  of  the  Indiana  Department  of 
Transportation  as  they  already  had  the  majority  of  the  other  permitting  and  licensing  functions. 
The  Purdue  team  thus  worked  with  INDOT,  the  Department  of  Revenue  and  finally  the  state's 
central  services  to  develop  a  Michigan  Train  permitting  solution. 

Because  of  their  expertise  in  the  overweight  truck  permit  process  and  in-depth  computer 
knowledge,  Purdue  was  asked  to  provide  services  by  assigning  Mr.  David  Moffett  and  Dr. 
Robert  Whitford.  The  work  plan  they  undertook  was: 

1.  To  evaluate  alternative  implementation  schema,  considering  the  various  systems 
available  on  the  market,  especially  those  being  used  in  the  banking  industry,  and 
develop  an  understanding  of  the  potential  for  the  present  Indiana  Department  of 
Revenue  Computer  to  accommodate  the  added  equipment  and  software  required  to 
effect  the  Michigan  Train  automatic  permit  process. 

2.  To  recommend  from  these  alternatives  a  single  approach  for  implementation. 

3.  To  generate  a  functional/operating  specification  for  the  system.  This  specification  is 
presented     in     Appendix     B.  The     related     flow     chart     is     shown     as 


1 .    Moffett,  David  P.  and  Whitford,  Robert  K.,  Development  of  Annual  Permit  Procedure  for  Overweight  Trucks  on  Indiana  Highways, 
FHWA/IN/JHRP-95/5  Final  Report,  December  3 1 ,  1 995. 


FIGURE  1  Flow  chart  reflecting  the  sequence  of  steps  in  automated  touch-tone 

system  for  obtaining  a  permit  for  Michigan  train. 
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Figure  1 .   It  shows  the  process  of  query,  answers  and  verification  as  the  caller  moves 
through  a  typical  process  of  obtaining  a  permit. 

4.  To  support  INDOT/Indiana  Department  of  Revenue  implementation. 

5.  Write  a  summary  report  (this  document). 

A  specification  was  generated  in  about  six  weeks  after  numerous  contacts  with  both 
INDOT  and  Department  of  Revenue  persons  directly  connected  with  the  activity. 

Because  of  the  nature  of  the  study  all  reports  were  in  draft  form  and  delivered  to  Mr. 
Zandi  for  his  use  in  the  INDOT  portion  of  responsibility  in  oversight  of  the  shift  of  the 
permitting  clerk  and  revenue  function  to  the  Department  of  Revenue  . 

Three  basic  concerns  were  the  subject  of  further  drafts  papers,  namely:  security,  vendor 
choice  and  maintaining  "audit-ability"  for  future  billing  and  information  retrieval  (audit  trails  are 
needed  for  potential  future  legal  action).  These  appear  as  Appendices  C,  D,  and  E,  respectively. 

The  work  by  Purdue  determined  the  version  of  the  Touch  Tone/Voice  Response  system 
that  is  best  suited  to  the  Michigan  Train  Permits  will  work  well  on  the  Indiana  Department  of 
Revenue  Computer.  Hardware  and  software  needs  are  straightforward  and  can  be  easily  met  by  a 
relatively  inexpensive  and  straightforward  expansion  of  the  existing  Taxpayer  Information 
System  (which  utilizes  IBM's  Direct-Talk  II  system)  that  IDR  already  has  extensive  experience 
in  using.  Expertise  in  the  form  of  an  experienced  vendor  who  set  up  much  of  the  original 
taxpayer  information  system  was  available  to  work  on  this.  This  expertise,  in  particular,  dealt 
especially  with  the  pre-existing  layers  of  security  that  EDR  uses. 


CHAPTER  2 
Implementation  Plan 

Because  of  the  nature  of  this  work  the  only  implementation  plan  that  is  appropriate  is  that 
the  permit  system  be  upgraded  to  complete  many  of  the  routine  permits  for  Overweight/Oversize 
trucks.  That  will  require  more  data  that  will  be  entered  by  the  telephone  keyboard,  but  the 
technical  capability  and  the  approach  is  basically  the  same  as  for  the  simpler  Michigan  Trains 
permit  data  requirements. 
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This  memo  contains  what  we  believe  will  accomplish  the  most  good  within  the  INDOT 
and  the  State  as  far  as  the  automation  of  permitting  for  Michigan  Trains.  The  memo  is 
broken  up  into  sections.  The  first  contains  a  small  background  about  the  principal  staff 
(David  Moffett).  Secondly  is  commentary  about  computing  environments.  The  third  is  a 
statement  of  the  goal  of  this  project.  Finally,  there  are  a  few  approaches  for  meeting  this 
goal. 

Personnel  Background 

David  Moffett  has  been  in  the  computer  industry  for  over  22  years.  He  knows  around 
twenty  computer  languages  and  has  designed  sophisticated  hardware  &  software  for 
computer  process  control.  Additionally,  he  has  taught  Software  Engineering,  Object- 
Oriented  Programming  and  software  design  theory  to  both  graduate  and  undergraduate 
Computer  Science  students.  He  is  currently  an  automation  and  technology  consultant  to 
several  businesses.  He  hold  a  B.S.  and  an  M.S.  in  Civil  Engineering  and  is  nearing 
completion  of  a  Ph.D. 

His  background  is  important  because  the  commentary  that  follows  depends  not  only  on 
the  technology  but  also  on  the  political  and  technical  arena  in  which  any  proposed 
solution  will  operate.  The  computer  industry's  history  is  full  of  technologically 
wonderful  projects  that,  in  the  end,  flop  because  either  the  technical  level  of  those  who 
operate  and  support  the  project  are  out  of  sync  with  the  project  or  the  politics  cause  the 
system  to  never  gain  acceptance.  In  the  State's  case,  there  has  been  a  shortage  of  new 
technology  oriented  people  with  in  INDOT.  These  facts  weigh  heavily  on  the  path 
selected  for  Michigan  Trains  automation  as  well  as  automation  for  permitting  in  general. 

Computing  Environments 

When  an  Information  Systems  (IS)  department  decides  on  hardware,  or  on  a  particular 
operating  system  that  they  will  use,  then  the  whole  philosophy  of  how  things  are  to  be 
done  is  decided  at  the  same  time.  The  State  of  Indiana  is,  and  for  quite  a  while  has  been, 
an  I.B.M.  shop.  By  selecting  I.B.M.,  decisions  about  which  operating  system  to  use  were 
considerably  narrowed  as  well  as  the  software  development  philosophy  that  will  be 
followed. 

The  State's  information  infrastructure  is  centered  around  IBM  hardware,  an  operating 
system  that  has  its  roots  in  the  1970s  and  a  strong  COBOL  programming  environment. 
Systems  that  are  able  to  interact  with  users  were  considered  by  I.B.M.  mostly  after  both 
the  core  hardware  and  operating  system  designs  were  complete.  As  a  result,  interactive 
programming  is  restricted  considerably.  Clearly,  a  programmer  would  much  rather  write 
interactive  programs  for  a  PC  or  for  one  of  many  newer  operating  systems.  The  I.B.M. 
mainframe  environment  excels  at  doing  batches  of  things  and  to  a  lesser  degree  deals 
with  on-going  user  interactions. 

Also,  when  the  I.B.M.  decision  was  made,  there  was  an  implicit  decision  to  hire  a  certain 
kind  of  programming  and  systems  staff.  These  people  are  usually  old-timers  who  have 
had  many  years  of  I.B.M.  experience.  They  are  often  very  highly  trained  for  the 
complexities  that  occur  when  using  I.B.M.  systems.  On  the  other  hand,  they  are  mostly 
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far  from  the  leading  edge  of  computing,  and  unless  special  pains  are  taken,  often  find 
themselves  technologically  obsolete  before  their  career's  are  over. 

This  background  is  important  because  a  Touch-Tone™/Voice  Response  system  is  much 
closer  to  the  leading  edge  than  much  of  what  is  typically  done  at  an  I.B.M.  shop.  Finding 
sufficient  staff  to  program,  debug,  and  support  such  a  system  in  house  will  probably  be  a 
problem. 

How  companies  typically  deal  with  the  introduction  of  new  technological  specialties  is  in 
one  of  several  ways.  Often,  companies  hire  new  talent  who  can  adequately  support  new 
technology.  At  the  moment,  companies  like  Federal  Express  in  Memphis,  TN  are  hiring 
large  numbers  of  Unix™  technical  staff  because  they  lack  a  Unix  knowledge  base. 
Sometimes,  new  technology  is  brought  in  as  a  black  box  by  the  company  buying  the 
technology  as  a  package.  Indiana  National  Bank  (now  NBD),  when  they  started  doing 
bank-by-phone,  purchased  a  very  expensive  package  written  by  one  of  very  few  specialty 
companies.  Subsequently,  the  in  house  staff  just  called  the  specialty  company  to  handle 
the  problems  as  they  came  arose.  Infrequently,  staff  that  already  is  employed  by  the 
company  is  sent  out  for  more  education  so  that  they  can  work  with  the  new  technology. 
In  aid  of  helping  old  staff  with  newer  technologies,  all  sorts  of  software  and  hardware 
vendors  offer  intermediate  products  or  building  blocks  that  hide  the  new  technology  in 
old  technology  wrappers. 

We  are  very  concerned  that  whatever  TT/VR  system  is  implemented  will  be  sufficiently 
well  supported  both  in  the  short  and  long  term.  It  will  need  to  be  a  "good  fit"  within  the 
rest  of  the  State's  information  infrastructure. 


The  Goal 

An  easily  implemented,  timely,  cost  effective,  supportable  system  to  automate  routine 
requests  for  Michigan  Train  permits  using  Touch  Tone/Voice  Response  technology. 
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Ways  of  Accomplishing  Our  Task 

With  the  preceding  said,  there  are  several  paths  that  can  be  taken.  In  the  coming  weeks 
we  will  attempt  to  understand  all  that  will  be  required  to  follow  one  or  another  of  these 
paths: 

1 .  Home  Grown  —  High  Technology 

2.  Home  Grown  —  Lower  Technology 

3.  Purchased  Systems  ~  I.B.M.  based 

4.  Purchased  Systems  ~  I.B.M.  interfaced 

By  "Home  Grown"  we  mean  systems  that  take  basic  building  blocks  of  hardware  and 
software  and  build  a  TT/VR  system  from  the  ground  up.  Home  Grown  systems  can 
either  be  written  by  in-house  programmers  or  contracted  out  with  a  specification  prepared 
in  house.  "Purchased  Systems"  are  like  those  acquired  by  banks  for  bank-by-phone  or 
many  other  externally  designed  and  written  systems.  Some  very  popular  purchased 
systems  are  core  accounting  and  payroll.  Accounting,  because  it  is  very  standard  and 
payroll  because  the  same  changes  are  needed  by  many  different  companies.  In  either 
case,  the  cost  of  doing  the  programming  is  distributed  across  many  customers  and  is  a 
cost  savings  to  everyone. 

Home  Grown  systems  are  much  more  flexible  but  always  will  need  more  support  from 
internal  resources.  Purchased  systems  are  usually  available  more  quickly,  are 
substantially  less  flexible  and  require  recurring  external  expenditures  to  maintain  the 
license  and  support  from  the  vendor. 

Some  details  and  comments  about  each  of  the  possible  paths  seem  appropriate  here. 

1.  Home  Grown  —  High  Technology 

If  we  were  on  our  own,  we  would  suggest  this  alternative.  We  would  ignore  the  support, 
political,  and  technological  problems.  As  a  result,  it  would  probably  fail  since  it  is 
probably  a  poor  fit  within  the  State's  information  infrastructure! 


Very  simply,  this  path  has  a  TT/VR  system  pretending  to  be  an  operator  at  a  normal 
terminal.  Few  changes  would  be  required  to  add  this  to  the  existing  system. 


Figure  1 


PC  based  Unix  computer 

-  Emulates  3270  terminal 

-  Contains  TT/VR  card 

-  Contains  script  and  login  info 

-  Contains  no  data  storage  other 
than  that  of  the  current  call. 


Appendix  A  -  4 


We  became  excited  by  this  alternative  because  it  can  be  done  cheaply,  using  off-the-shelf 
hardware,  and  with  a  small  software  development  effort.  The  disadvantage  is  that  there  is 
little  Unix  experience  inside  the  state  and  so  software  development  will  be  a  problem. 

2.  Home  Grown  —  Lower  Technology 

IBM  sells  TT/VR  hardware  that  interfaces  with  existing  IBM  hardware.  While  we  have 
no  experience  with  it,  nor  have  we  had  a  recent  look  at  the  pricing  for  it,  we  know  a  few 
years  ago  it  was  quite  expensive,  especially  when  compared  to  the  costs  in  Alternative  #1. 
However,  their  hardware  will  fit  as  well  as  any  with  the  IBM  way  of  doing  things.  Our 
information  on  this  equipment  is  old,  and  we  will  update  it.  We  think  that  it  interfaces  to 
the  host  approximately  like  Figure  2. 


unknown 

IBM  Host 

y^"^\. 

IBM  TT/VR 
hardware 

phone  line         /                       \ 
w|  User  with         \ 

^1    11  phone         1 

FIGURE  2 

^ ' 

The  major  problem  with  such  an  implementation  is  that  then  there  needs  to  be  a 
substantial  programming  effort  on  the  IBM  computer  in  order  to  have  the  TT/VR 
hardware  function. 

3.  Purchased  Systems  —  I.B.M.  based 

A  purchased  system,  that  is  IBM  based,  will  look  much  like  Figure  2.  We  are  not 
particularly  optimistic  about  the  possibility  of  this  path  for  two  reasons.  First,  we  think 
that  the  Michigan  Trains  permitting  problem  is  a  sufficiently  odd  application  that,  at  best, 
we  could  suggest  buying  purchased  modules  that  would  have  to  then  be  glued  together  by 
state  programmers  or  by  a  contractor  working  closely  with  State  IS  staff.  Second,  we  are 
only  aware  of  firms  selling  complete  products  for  IBM  hardware.  Thus,  even  finding 
someone  who  is  willing  to  sell  modules  is  a  problem  in  its  own  right. 

This  option  is  separate  from  #4  because  the  great  majority  of  the  computing  is  done  on 
the  IBM  host. 

4.  Purchased  Systems  —  I.B.M.  interfaced 

Much  like  our  alternative  #1,  we  would  not  be  surprised  to  find  various  vendor's  products 
working  on  stand-alone  computers  connected  to  the  IBM  host.  Here  again,  we  are  not 
familiar  with  current  vendors,  but  expect  that  the  oddness  of  the  application  will  not  lend 
itself  to  a  pre-packaged  complete  solution.  These,  if  they  can  be  found,  will  look  like 
figure  3. 
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Figure  3 


Work  Plan 

Three  tasks  are  anticipated  that  will  be  done  in  the  few  weeks: 

1 .  Develop  a  system  specification  and  several  proposed  implementation  approaches 

2.  Work  with  INDOT  to  identify  the  interface  problems  with  their  present  system. 

3.  Prepare  a  concise  work  plan  to  get  Michigan  Trains  automated. 

Budget 


Whitford  -  10%  -  July  15  -  October  15,  1995 
Moffett  -  50%  -  July  15  -  October  15,  1995 
Travel  to  Indy  -  10  trips 


$2000 
$3360 
$  265 

$5625 


Closing  Remarks 

In  working  with  the  state  on  permitting,  we  have  found  that  lots  of  studies  and  reports 
have  been  written,  and  yet  the  problems  still  remain.  We  hope  to  report  updates  of  our 
work  on  a  timely  basis.  These  updates,  as  a  set,  will  constitute  our  final  report,  since  we 
hope  that  our  real  final  report  is  a  concise  work  plan  to  get  Michigan  Train  permitting 
automated. 

The  State  already  has  at  least  one  Touch-Tone/Voice  Response  system  installed  and 
working.  It  is  part  of  the  Indiana  Department  of  Revenue  and  allows  taxpayers  to  check 
on  the  disposition  of  their  tax  refund  [the  number  is  (317)  233-4018].  We  will  explore 
how  this  was  implemented  and  hope  that  the  DDR  solution  methodology  is  one  that  can  be 
easily  transferred  to  that  of  Michigan  Trains. 

Finally,  projects  like  this  one  are  not  done  in  a  vacuum.  If  you  have  questions  or 
comments  please  feel  free  to  contact  us. 
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ABSTRACT 


This  is  a  DRAFT  functional  specification  for  the  automation  of  the  permitting 
process  for  a  subset  of  overweight  vehicles  using  the  "extra  heavy  duty  highway"  in 
northern  Indiana.  These  vehicles  are  often  known  as  "Michigan  Trains".  The  automation 
is  by  means  of  a  computer  controlled  voice  interacting  with  a  user  who  is  entering 
information  by  DTMF  telephone. 

This  specification  covers  the  user  interaction  and  supplemental  logging  of  such 
transactions.    It  presents  three  alternatives  that  the  state  should  consider  before 
implementation  begins.    It  does  not  cover  the  necessary  changes  to  be  made  to  the 
existing  system,  though  those  changes  can  be  easily  implied.    Some  notes  about  each 
alternative  follow. 


1.  System  Configuration 


2.  Notation 

Items  in  square  brackets  are  characters  a  user  keys  in  by  their  telephone  dial.  [9] 
means  they  pressed  the  number  9. 

Items  in  italics  are  spoken  by  the  voice  response  system.  Welcome  is  an  example. 

Items  in  curly  braces  {  }  are  reference  points  for  notes.  They  are  not  part  of  the 
script.    Note  numbers  are  not  reused  from  one  alternative  to  another  and  frequently  refer 
to  another  alternative. 

3.  Alternatives 

3.1.  Alternative  1  -  Optimal  for  User  Use 


Appendix  B  -  1 


3.1.1.  Overview 

This  alternative  eliminates  as  many  keystrokes  as  possible  to  reduce  the 
complexity  to  the  user  as  well  as  shorten  the  call's  duration.  Reduced  call  durations  yield 
a  better  level  of  service  for  all  users. 

This  alternative  introduces  a  new  number  as  well  as  a  PIN  to  the  system.  The 
system  impact  means  that  this  number  must  be  looked  up  to  gain  the  truck,  company  and 
if  applicable,  the  annual  permit  number.  Then  the  system  looks  these  numbers  up 
without  bothering  the  user. 


3.1.2.  Interaction 

Here  is  a  sample  interaction 
[8][0][0]  [x][x][x]  [x][x][x][x] 
Welcome  to  the  State  of  Indiana's  automated  permit  granting  system. 

{1} 

Enter  your  permit  automation  number  followed  by  a  star. 

Enter  zero  star  for  more  information  on  this  system: 

[0][*] 

The  State  of  Indiana's  automated  permit  granting  system 
allows  for  fully  automated  granting  of  some  kinds  of  over 
weight  truck  permits.  This  system  is  usually  available  24 
hours  a  day,  seven  days  a  week.  Before  using  this  system, 
users  must  have  already  been  enrolled  with  the  state. 
Enrollment  includes  providing  the  state  with  various  infor- 
mation about  your  company,  insurance,  vehicle  and  method  of 
paying  for  the  permits. 

For  operator  assistance  dial  800-xxx-xxxx.  {3} 

Enter  your  permit  automation  number  followed  by  a  star. 
Enter  zero  star  for  more  information  on  this  system: 

[1][2][3][4][5][6][*] 

Enter  the  personal  identification  number  followed  by  a  star: 

[1][2][4][3][*] 
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You  have  entered  an  incorrect  permit  number  or  PIN.    Please 
reenter  the  permit  automation  number  followed  by  a  star: 

[1][2][[3][4][5][6][*] 

Enter  the  personal  identification  number  followed  by  a  star: 

[1][2][3][4][*] 

Thank  You 

{9} 

Enter  the  date  on  which  the  permit  should  be  effective.  {3} 

Press  the  four  digits  of  the  year,  two  digits  for  the  month, 
two  digits  for  the  day  and  then  a  star. 

[1][1][9][5][1][2][1][2][*] 

The  date  entered  has  already  occurred.  Please  reenter  the 
date: 

Press  the  four  digits  of  the  year,  two  digits  for  the  month, 
two  digits  for  the  day  and  then  a  star. 

[1][9][9][5][2][1][2][*] 

The  date  entered  does  not  have  enough  digits.  For  days  and 
months  that  are  single  digits,  be  sure  to  place  a  zero  in 
front  of  them. 

Press  the  four  digits  of  the  year,  two  digits  for  the  month, 
two  digits  for  the  day  and  then  a  star. 

[1][9][9][5][4][2][1][2][*] 

The  month  entered  is  larger  than  twelve.  Please  reenter  the 
date: 

Press  the  four  digits  of  the  year,  two  digits  for  the  month, 
two  digits  for  the  day  and  then  a  star. 

[1][9][9][5][1][2][1][2][*] 

Is  December  twelfth  nineteen  ninety-five  correct?  Press  one 
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for  yes,  zero  for  no. 

[2] 

In  incorrect  response  was  entered. 

Is  December  twelfth  nineteen  ninety  five  correct?  Press  one 
for  yes,  zero  for  no. 

[1] 
{11} 


Enter  the  type  of  load  this  vehicle  will  be  carrying.  Press 
zero  then  star  for  a  menu  of  possible  load  types: 

[OF] 

The  possible  load  types  are  each  numbered.   The  number  fol- 
lowing each  type  is  the  number  that  should  be  entered. 

corn  -  one 

hot  asphalt  -  two 
steel  plate  -  three 
steel  coil  -four 
or 
other  -  nine 

Enter  the  type  of  load  this  vehicle  will  be  carrying.  Press 
zero  then  star  for  a  menu  of  possible  load  types: 

[4][*] 

Is  steel  coil  correct?  Press  one  for  yes,  zero  for  no. 

[1] 

Enter  the  origin  number  followed  by  a  star.  Press  zero  then 
star  for  a  menu  of  possible  origins: 

[0][*] 

The  possible  origins  are  each  numbered.  The  number  follow- 
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ing  each  name  is  the  number  that  should  be  entered.  {4} 

Burns  Harbor  -  one 

East  Chicago  -  two 

Furnaceville  -  three 

Gary  -four 

Hammond  -five 

Michigan  City  -  six 

New  Carlisle  -  seven 

Portage  -  eight 

Porter  -  nine 

Rolling  Prairie  -  ten 

South  Bend  -  eleven 

Springville  -  twelve 

Westfield  -  thirteen 

or 

Michigan  State  Line  -fourteen 

Enter  your  origin  number  followed  by  a  star.  Press  zero 
then  star  for  a  menu  of  possible  origins: 

[1][*] 

Is  Burns  Harbor  correct?  Press  one  for  yes,  zero  for  no. 

[1] 

Enter  your  destination  number  followed  by  a  star.    Press 
zero  then  star  for  a  menu  of  possible  destinations: 

[0][*] 

The  possible  destinations  are  each  numbered.   The  number 
following  each  name  is  the  number  that  should  be  entered. 

Burns  Harbor  -  one 
East  Chicago  -  two 
Furnaceville  -  three 
Gary  -four 
Hammond  -five 
Michigan  City  -  six 
New  Carlisle  -  seven 
Portage  -  eight 
Porter  -  nine 
Rolling  Prairie  -  ten 
South  Bend  -  eleven 
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Springville  -  twelve 

Westfield  -  thirteen 

or 

Michigan  State  Line  -fourteen 

Enter  your  destination  number  followed  by  a  star.    Press 
zero  then  star  for  a  menu  of  possible  destinations: 

[1][4][*] 

Is  Michigan  State  Line  correct?  Press  one  for  yes,  zero  for 
no. 

[1] 

Your  account  has  been  charged. 

Your  permit  number  is  zero  one  two  three  four. 

Press  one  to  have  the  permit  number  repeated.  Press  zero  to 
continue. 

[1] 

Your  permit  number  is  zero  one  two  three  four. 

Press  one  to  have  the  permit  number  repeated.  Press  zero  to 
continue. 

Press  one  to  request  another  permit,  zero  to  finish  this 
call. 

[0] 
{7} 

Thank  You. 

click. 

3.1.3.  Notes: 

1 .  This  is  the  return  point  for  gaining  multiple  permits 

2.  This  is  the  normal  voice  800  number. 
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3.  Date  validation  should  cover  month  range,  day  range  within  the  month,  year, 
and  then  make  some  good  guesses  about  incorrect  order  of  entry.  Dates  before  the 
current  date  are  also  unacceptable.  Space  should  be  left  in  the  system  for  entering  a  time 
following  the  date  as  there  is  discussion  about  making  the  permits  valid  for  24  hours 
starting  at  whenever  they're  requested  to  start. 

4.  The  origin  and  destination  lists  are  from  "Truck  Talk  about  Michigan  Trains" 
dated  August  1,  1994.  They  are  presented  in  alphabetical  order. 

5.  Load  types  are  those  that  Purdue  discovered  during  the  previous  study.  There  may 
be  others.  They  are  presented  in  alphabetical  order. 

6.  Three  incorrect  permit  automation  number/PIN  number  pairs  should  terminate  the 
call  and  generate  log  messages  to  that  affect. 

7.  If  the  user  had  requested  another  permit  number,  they  should  be  returned  back  to 
{ 1 } .  A  limit  often  permits  per  call  seems  very  reasonable.  The  current  utilization 
pattern,  namely  multiple  permits  per  call,  Purdue  believes  will  end  if  this  system  is 
always  available,  reliable  and  very  infrequently  busy. 

8.  The  order  of  questions  is  the  same  as  those  presented  currently  by  the  operator. 

9.  This  is  an  entry  point  for  some  of  the  other  alternatives. 

10.  Marker  in  Alternative  2 

1 1 .  This  is  an  entry  point  for  another  alternative. 

3.2.  Alternative  2  -  PIN  with  little  System  &  Programming  Impact 

3.2.1.  Overview 

This  alternative  requires  more  user  knowledge  about  how  they  are  permitted.  In 
particular  it  needs  to  know  how  the  truck  is  permitted  (either  annual  or  per-call)  as  well 
as  truck  and  company  number. 

This  alternative  introduces  a  PIN  to  the  system.    See  the  commentary  on  PIN 
numbers. 

One  major  complication  that  this  method  has  is  the  letter  that  is  the  last  character  of 
the  company  number.    The  normal  telephone  keypad  has  letters,  but  they  are  not  unique 
to  a  key  (three  letters  per  key  usually).  Thus  is  one  is  told  to  press  "A",  there  are  three 
letters  that  could  be,  namely  "A",  "B",  and  "C".  Further,  there  is  also  confusion  about  the 
difference  between  the  letter  O  and  the  number  0.  Further,  two  letters  are  missing  off  the 
traditional  DTMF  keypad,  namely  Q  and  Z. 
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Another  substantial  complication  is  the  single-trip  permit's  need  for  substantial 
alphanumeric  entry. 

3.2.2.  Interaction 

[8][0][0]  [x][x][x]  [x][x][x][x] 

Welcome  to  the  State  of  Indiana's  automated  permit  granting 
system. 

{1} 

Enter  your  company  number  excluding  the  trailing  letter. 

Enter  zero  star  for  more  information  on  this  system: 

[0][*] 

The  State  of  Indiana's  automated  permit  granting  system 
allows  for  fully  automated  granting  of  some  kinds  of  over 
weight  truck  permits.  This  system  is  usually  available  24 
hours  a  day,  seven  days  a  week.  Before  using  this  system, 
users  must  have  already  been  enrolled  with  the  state. 
Enrollment  includes  providing  the  state  with  various  infor- 
mation about  your  company,  insurance,  vehicle  and  method  of 
paying  for  the  permits. 

For  operator  assistance  dial  800-xxx-xxxx.  {3} 

Enter  your  company  number  excluding  the  trailing  letter. 
Enter  zero  star  for  more  information  on  this  system: 

[1][2][[3][4][5][*] 

Press  the  key  that  has  the  final  number  on  it.  For  Q  or  Z 
press  one. 

[4] 

Press  the  position  on  the  key  that  the  letter  holds.  For 
the  first  letter  on  the  key  press  one,  for  the  second  letter 
on  the  key  press  two,  for  the  third  letter  on  the  key  press 
three.  For  Q  press  one,  for  Z press  two. 

[2] 

Is  I2345H  the  correct  company  number?  Press  one  for  yes, 
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zero  for  no. 

[1] 

{17} 

Enter  the  personal  identification  number  followed  by  a  star: 

[1][2][4][3][*] 
{18} 

Thank  You 


{9} 

Enter  the  date  on  which  the  permit  should  be  effective.  {3} 

Press  the  four  digits  of  the  year,  two  digits  for  the  month, 
two  digits  for  the  day  and  then  a  star. 

[1][9][9][5][1][2][1][2][*] 

Is  December  twelfth  nineteen  ninety-five  correct?  Press  one 
for  yes,  zero  for  no. 

[1] 


Enter  one  if  this  is  permitted  on  an  Annual  Permit  or  two  if 
it  is  a  single  trip  permit. 

{10} 
[1] 

Enter  the  annual  permit  number  followed  by  a  star. 

[1][2][3][4][5][*] 

At  this  point,  the  remainder  of  the  permit  process  is  as  it 
was  in  alternative  1 .  Join  that  script  at  {11}. 

Single  Trip  Permit  Inset 


{12} 
[2] 

Enter  the  last  five  digits  of  the  truck  serial  number  fol- 
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lowed  by  a  star. 

[9][9][9][9][9][*] 

Enter  the  number  of  the  make  of  the  truck  followed  by  a 
star.  Press  zero  then  star  for  a  list  of  possible  makes. 

[0][*] 

The  possible  trucks  brands  are  each  numbered.    The  number 
following  each  name  is  the  number  that  should  be  entered. 
{13} 

Ford  -one 

General  Motors  -  two 

International  Harvester  -  three 

Mac  Truck  -four 

Navstar  International  -five 

Peterbilt  -  six 

Saab  -  seven 

Volvo  -  eight 

White  -  nine 

or 

Other  -  ninety-nine 

Enter  the  number  of  the  make  of  the  truck  followed  by  a 
star.  Press  zero  then  star  for  a  list  of  possible  makes 

[4][*] 

Is  Mac  Truck  correct?  Press  one  for  yes,  zero  for  no. 

[1] 


{14} 

Enter  the  state  or  province  that  the  tractor  is  licensed  in 

followed  by  a  star.  Press  zero  star  for  a  list  {15} 

[0][*] 

The  possible  states  and  provinces  are  each  numbered.  The 
number  following  each  local  is  the  number  that  should  be 
entered.  {13} 

In  the  United  States:  Alabama  -  one  Alaska  -  two  Arizona  - 
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three  Arkansas  -  four  American  Samoa  -five  California  -  six 
Colorado  -  seven  Connecticut  -  eight  Delaware  -  nine  Dis- 
trict of  Columbia  -  ten  Federated  States  of  Micronesia  - 
eleven  Florida  -  twelve  Georgia  -  thirteen  Guam  -  fourteen 
Hawaii  -fifteen  Idaho  -  sixteen  Illinois  -  seventeen  Indi- 
ana -  eighteen  Iowa  -  nineteen  Kansas  -  twenty  Kentucky  - 
twenty-one  Louisiana  -  twenty-two  Maine  -  twenty-three  Mar- 
shall Islands  -  twenty-four  Maryland  -  twenty-five  Mas- 
sachusetts -  twenty-six  Michigan  -  twenty-seven  Minnesota  - 
twenty-eight  Mississippi  -  twenty-nine  Missouri  -  thirty 
Montana  -  thirty-one  Nebraska  -  thirty-two  Nevada  -  thirty- 
five  New  Hampshire  -  thirty-six  New  Jersey  -  thirty-seven 
New  Mexico  -  thirty-eight  New  York  -  thirty-nine  North  Car- 
olina -forty  North  Dakota  -  forty-one  Northern  Mariana 
Islands  -forty-two  Ohio  -forty-three  Oklahoma  -forty-four 
Oregon  -forty-five  Palau  -forty-six  Pennsylvania  -  forty- 
seven  Puerto  Rico  -forty-eight  Rhode  Island  -forty-nine 
South  Carolina  -fifty  South  Dakota  -fifty-one  Tennessee  - 
fifty-two  Texas  -  fifty-three  Utah  -fifty-four  Vermont  - 
fifty-five  Virgina  -fifty-six  Virgin  Islands  -  fifty-seven 
Washington  -fifty-eight  West  Virgina  -fifty-nine  Wisconsin 
-  sixty  Wyoming  -  sixty-one  in  Canada 
...  in  Mexico 


Enter  the  state  or  province  that  the  tractor  is  licensed  in 
followed  by  a  star.  Press  zero  star  for  a  list 

[1][8][*] 

{16}   Character  by  character  the  license  plate  number  needs 
to  be  entered.  Press  a  single  star  when  entering  is  com- 
plete. 

Press  I  if  the  first  character  is  a  number,  2  if  it  is  a 
letter  or  star  to  finish.  {16} 

[1] 

Please  enter  the  first  digit 

[1] 

Press  I  if  the  second  character  is  a  number,  2  it  is  is  a 
letter  or  star  to  finish. 
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[1] 

Please  enter  the  second  digit 

[8] 

Press  1  if  the  third  character  is  a  number,  2  if  it  is  a 
letter  or  star  to  finish. 

[1] 

Please  enter  the  third  digit 

[6] 

Press  1  if  the  fourth  character  is  a  number,  2  if  it  is  a 
letter  or  star  to  finish. 

[1] 

Please  enter  the  fourth  digit 

[8] 

Press  1  if  the  fifth  character  is  a  number,  2  if  it  is  a 
letter  or  star  to  finish. 

[2] 

Press  the  key  that  has  the  final  number  on  it.  For  Q  or  Z 
press  one. 

[8] 

Press  the  position  on  the  key  that  the  letter  holds.  For 
the  first  letter  on  the  key  press  one,  for  the  second  letter 
on  the  key  press  two,  for  the  third  letter  on  the  key  press 
three.  For  Q  press  one,  for  Z  press  two. 

[1] 

Press  1  if  the  first  character  is  a  number,  2  if  it  is  a 
letter  or  star  to  finish. 

[*] 
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Is  1868t  correct?  Press  one  for  yes,  zero  for  no. 
[1] 


At  this  point,  the  remainder  of  the  permit  process  is  as  it 
was  in  alternative  1 .  Join  that  script  at  {11}. 


3.2.3.  Notes: 

10.  At  this  point,  there  is  a  split  in  the  interaction  depending  on  the  user's 
response.  If  they  reply '1',  then  continue  following  the  script.  If  they  reply  '2',  first 
interaction  is  for  annual  permitted  trucks.  The  second  is  for  pay-by-trip  vehicles  at 
marker  {12}. 

13.  Further  research  will  need  to  be  made  to  assure  this  list  is  complete. 

14.  At  this  point  things  begin  to  get  really  pretty  complicated.  Both  the  state  the 
license  plate  is  from  and  the  actual  plate  data  entry  are  painful,  tedious  and  consuming 
time  into  the  TT/VR  system. 

15.  One  alternate  way  to  do  this  instead  of  a  menu  is  have  the  user  spell  out  the  state 
on  the  keypad  and  then  hope  to  look  that  up  as  a  number  to  cross  reference  it  to  a  state 
name.  Then,  the  state  name  would  have  to  be  confirmed  as  is  done  here. 

16.  The  TT/VR  vendors  may  have  a  better  way  to  do  this,  but  it  is  not  likely. 
3.3.  Alternative  3  -  Minimal  System  &  Programming  Impact 

3.3.1.  Overview 

Remove  the  PIN  part  of  Alternative  2  which  is  between  {17}  and  {18} 

3.3.2.  Notes: 

See  the  separate  commentary  on  PINless  security. 
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Appendix  C 

Draft  Commentary  on  Touch  Tone™/Voice  Response 
System  Security  for  Michigan  Trains 


Quick  Study  on  Michigan  Train  Permitting 

Draft  Commentary  on  Touch  Tone™/Voice  Response 
System  Security  for  Michigan  Trains 


David  Moffett 
Purdue  University,  School  of  Civil  Engineering 


One  question  that  is  sure  to  come  up  with  respect  to  Purdue's  TT/VR  system 
specification  for  the  issue  of  whether  to  add  a  PIN  (personal  identification  number)  or 
not.    This  document  attempts  to  address  the  pros  and  cons  of  that  issue. 

Rick  Good  of  Indiana  Department  of  Revenue  makes  a  good  case  against  adding  a 
PIN  to  the  system.  The  essence  of  his  arguments  are  two  quite  valid  points. 

1 .  The  existing  system  does  not  have  a  means  of  securely  identifying  a  caller. 

2.  As  a  result  of  [1 .],  there  is  no  need  to  add  a  PIN  to  the  system  because  it  is  based 
on  top  of  a  system  that  is  less  secure  than  what  a  PIN  offers. 

Purdue's  position  is  that  inherent  to  the  existing  system  is  some  sanity  checking. 
The  permit  clerk  is  the  ultimate  arbitrator  of  the  validity  of  the  caller.  With  TT/VR  the 
state  has  lost  two  security  assets. 

One  case  comes  to  mind  that  will  certainly  happen  sooner  or  later  in  a  PINless 
system  which  brings  this  out. 

If  a  company  has  a  permit  clerical  that  is  terminated  or  quits  under  less  than 
optimal  conditions,  what  is  to  prevent  that  clerical  from  dialing  the  TT/VR  system  at  2 
A.M.  and  racking  up  dozens  if  not  hundreds  of  bogus  permits?  There  will  be  no  waiting 
to  retard  their  actions  nor  will  their  be  an  state  permit  clerk  to  get  an  unpleasant  feeling 
about  the  call  and  ask  questions.  Further,  after  such  an  event  is  detected,  the  only  way  to 
prevent  more  such  calls  is  to  issue  the  firm  a  new  company  number  which  seems  lengthy 
and  confusing. 

With  a  PEN  based  system,  when  the  clerical  person  departs,  their  supervisor  can 
call  the  state  and  have  the  PIN  changed.  At  that  time  the  permit  clerk  can  check 
extensively  to  assure  themselves  that  the  person  changing  the  PIN  has  that  right.  The 
firms  insurance  carrier  and  a  variety  of  dates  which  would  not  normally  be  used  in  the 
permit  acquisition  process  are  all  supplemental  pieces  of  information  that  can  be  used  to 
validate  that  the  supervisor  is  who  they  say  they  are.  This  is  similar  to  the  too  often  used 
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"mother's  maiden  name"  that  credit  card  companies  have  used  for  caller  authentication 
for  over  thirty  years. 

Ever  since  the  permitting  process  was  understood  by  Purdue,  a  wide  variety  of 
security  questions  have  been  left  unanswered.  Introducing  a  PIN  just  assures  that  the 
introduction  of  TT/VR  does  not  further  weaken  a  system  which  should  be  viewed  as 
already  questionably  secure. 
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Draft  Commentary  on  Touch  Tone™/Voice  Response 
System  Vendor  for  Michigan  Trains 

David  Moffett 

Purdue  University, 

School  of  Civil  Engineering 


Purdue  is  quite  concerned  about  the  relative  merits  of  the  two  proposed  system 
vendors  for  the  hardware  and  core  software  of  the  Michigan  Train  TT/VR.  It  should  be 
noted  that  neither  Purdue,  nor  either  of  the  researchers  have  any  known  monetary  interest 
in  either  system  or  vendor. 

Without  regard  for  the  arcane,  lengthy  and  counter-productive  procurement  rules 
within  the  state,  Purdue  believes  that  expansion  of  the  system  already  installed  within 
the  Indiana  Department  of  Revenue  is  a  substantially  superior  option. 

Purdue's  belief  is  based  on  the  following  areas: 

1 .  EDR  has  substantial  and  presently  available  working  knowledge  of  the  IBM  Direct- 
Talk  II  system.  This  knowledge  will  certainly  allow  for  a  quicker  time  to  Michigan 
Train's  TT/VR  system  being  available  for  production  use. 

2.  IDR  has  a  "professional  services"  consultant  for  the  IBM  TT/VR  system  that  is 
already  up  to  speed  with  the  way  IDR  operates  its  system.    The  consultant  resides  in  the 
Indianapolis  area  and  thus  is  readily  available  for  both  immediate  problems  and  the  likely 
possible  enhancements  of  such  a  system. 

3.  The  Ameritech  system  is  under  a  2+2  lease  to  the  state.  That  means  that  two  years 
after  the  system's  first  lease  was  signed,  a  renewal  might  be  signed.  At  the  end  of  four 
years  then  the  system  might  be  purchased  by  the  state,  might  by  re-leased  or  might  be 
returned  to  the  vendor.    At  present,  the  state  is  approximately  eight  months  into  the  first 
of  the  two  two-year  periods. 

This  means  that  if  the  Ameritech  system  was  selected,  it  is  quite  possible  that  in  either 
16  months  or  40  months  the  system  would  be  removed  from  service  and  the 
programming  effort  predominately  lost  that  went  into  such  a  system. 

The  IBM  system's  proposal  is  for  a  purchase/expansion  and  thus  has  no  limit  on  it's 
duration  within  Revenue.  It  not  unreasonable  to  expect  systems  such  as  this  to  last  at 
least  five  years. 
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4.  The  IBM  system  is  already  supported  within  IDR.    The  addition  of  a  different 
system  will  require  additional  substantial  recurring  person  hours  to  assure  that  software 
updates  and  external  changes  that  occur  to  the  IDR  computer  environment  are  reflected 
back  into  two  different  kinds  of  systems  instead  of  just  one.  The  recurring  costs  are 
difficult  to  estimate  because  the  future  if  the  DDR  computer  system  is  difficult  to  predict. 

5.  The  IBM  system's  costs  are  sufficiently  small  that  even  if  the  system  was  retired  at 
5  years  and  the  hardware  scrapped  the  state  would  have  received  substantial  value  over 
and  above  what  the  system  cost. 

6.  The  degree  of  difficulty  in  dealing  with  Ameritech,  then  its  subcontractors  and  then 
their  vendors  adds  the  unpleasant  possibility  of  finger  pointing  between  four  or  more 
different  parties  (DDR,  Ameritech,  the  contract  programming  firm,  the  hardware 
vendor,  IBM...).  Finger  pointing  is  a  classic  problem  that  happens  in  a  heterogeneous 
environment  where  each  party  blames  the  other  on  something  not  working  as  it  should. 
The  IBM  alternative  is  a  single  source  responsibility  as  the  vendor  is  a  business  partner 
with  IBM. 

As  of  this  writing,  Purdue  has  not  received  the  Ameritech  cost  estimate. 
However,  even  if  it  was  free  (which  it  certainly  will  not  be),  the  time-to-tum-on  & 
support  for  the  IBM  system  and  uncertain  availability  and  development  of  the  Ameritech 
system  would  have  Purdue  select  the  IBM's  system  expansion. 
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Draft  Commentary  on  Touch  Tone™/Voice  Response 
System  Auditability  for  Michigan  Trains 


David  Moffett 
Purdue  University,  School  of  Civil  Engineering 


Purdue  (Bob  Whitford  and  David  Moffett)  is  concerned  that  the  ability  to  audit  any 
proposed  Touch  Tone™/Voice  Response  system  is  not  being  sufficiently  considered. 
This  note  discusses  the  topic  from  a  variety  of  directions  and  supports  what  we  have 
required  in  our  TT/VR  specification.  Obviously,  since  Purdue  is  acting  as  only 
consultants  to  this  project,  the  state  has  the  right  to  revise  that  proposed  specification,  but 
if  it  does,  it  goes  against  Purdue's  better  judgment. 


1.  Background 


1.1.  The  current  permitting  system. 

The  existing  operator  based  system  is  operators  talking  to  users  by  voice  or 
facsimile.  In  the  case  of  voice,  the  entire  conversation  is  tape  recorded  on  two  magnetic 
tapes.  One  of  these  tapes  is  used  for  immediate  replay,  if  there  is  any  confusion  and  the 
other  is  held  as  an  archive  of  the  interaction  for  as  long  as  the  Indiana  records  law 
requires.  Facsimile  transactions  are  on  paper  and  thus  are  subject  to  substantially  less 
opportunity  for  ambiguity.  Permits  issued  by  the  various  district  offices  are  not  recorded. 

As  a  result,  if  a  major  crash  occurs  to  the  computer  system  and  transactions  already 
in  the  computer  are  lost,  playing  back  the  tape  and  re-entering  the  transactions  allows  the 
majority  of  the  transactions  to  be  recovered  with  the  user  being  unaware  there  was  even  a 
problem.  This  also  means  that  the  billing  that  is  generated  off  these  transactions  can  go 
on  un-encumbered. 

1.2.  The  current  TT/VR  applications  in  IDR. 

There  are  two  applications  in  production  in  the  Department  of  Revenue.  One  is 
the  taxpayer  refund  line.  It  allows  the  user  to  know  information  about  their  tax  refund. 
The  other  is  information  about  personal  property  tax  due.  Both  systems  are 
INFORMATION  ONLY  systems.  Though  the  logs  all  the  calls,  no  revenue  is  lost  if  the 
transactions  are  totally  lost  due  to  computer  failure. 

2.  What  is  proposed 
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The  Michigan  Train  TT/VR  application  dispenses  permit  numbers  in  exchange  for 
money.  If  a  transaction  is  lost  two  problems  appear.  First,  the  state  loses  $42.50  in 
revenue.  Second,  if  there  is  a  question  by  law  enforcement  about  the  validity  of  a  permit, 
the  permit  office  will  be  unaware  a  permit  was  issued,  because  the  transaction  was  lost. 
If  this  occurs,  the  user  might  be  ticketed  incorrectly  and  the  state  would  then  be  exposed 
to  a  lengthy  set  of  complaints  and/or  litigation  about  the  permitting  process. 

Purdue  believes  that  it  is  unacceptable  to  lose  any  transactions. 

As  a  result,  the  specification  calls  for  a  supplementary  record  of  all  transactions  to 
be  held  in  the  TT/VR  system  until  after  at  least  one  backup  has  been  made  of  the  host 
computer  on  which  the  permitting  system  resides.    As  such,  these  transactions  can  be 
recovered  should  the  permitting  system  database  be  lost  back  to  the  previous  backup  from 
a  hardware  or  software  fault.  This  then  assures  that  the  state  can  recover  all  the  revenue 
it  is  owed  and  there  is  no  new  exposure  to  problems  beyond  that  already  in  the  existing 
system. 

The  archive  kept  by  the  TT/VR  system  will  also  need  to  keep  the  permit  number 
issued  so  that  the  database  can  be  restored  completely  to  its  correct  state  previous  to  any 
host  computer  crash. 

The  other  possible  failure  mode,  namely  the  TT/VR  system  crashing  does  not 
substantially  hurt  the  validity  of  the  data,  unless  the  truly  weird  happens  and  both  the 
host  and  TT/VR  systems  crash  simultaneously.  Purdue  views  the  probability  of  this 
happening  as  sufficiently  small  to  not  be  worried  about  it. 

In  either  case,  a  crash  may  result  in  transactions  in  process  being  left  in  an 
indeterminate  state.  The  log  file  kept  on  the  TT/VR  system  will  help  straighten  out  such 
problems. 

If  the  internal  auditors  were  interested,  it  would  be  a  straight  forward  matter  to 
check  between  the  hosts  database  and  the  TT/VR  log  to  assure  that  the  same  number  of 
permits  were  issued  by  TT/VR  means.  This  is  in  essence  a  double  entry  system  and 
should  be  familiar  to  the  auditors.  Purdue  believes  that  each  of  the  TT/VR  transactions 
should  be  at  least  attributable  to  TT/VR  in  the  host  database,  and  preferably  even  which 
line  was  used.    This  will  aid  considerably  in  process  of  back  tracking  to  find  where 
particular  transactions  went  astray  should  there  be  a  problem. 


3.  Supplemental  Check  Digit 

Supplemental  or  perhaps  alternative  to  the  logging  of  all  transactions  is  the 
introduction  of  a  numeric  check  digit  to  the  permit  number.  The  goal  of  this  would  be  to 
determine,  given  a  permit  number,  if  it  was  valid.  There  is  substantial  previous  use  of 
such  systems  in  two  of  the  largest  numbering  systems  in  the  world,  namely  the  Universal 
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Product  Code  (UPC)  and  the  International  Standard  Book  Number  (ISBN).  In  both  cases, 
with  just  the  number,  one  can  determine  if  the  number  is  a  valid  one. 

The  core  to  such  a  scheme  is  the  computation,  in  some  sophisticated  way,  of  a 
check  digit  that  is  added  to  the  front  or  back  of  the  permit  number.  This  would  ease  the 
state's  problems  of  being  given  a  number  by  law  enforcement  but  being  unsure  if  it  was  a 
valid  number  or  one  made  up  to  avoid  getting  into  trouble. 


If  Purdue  were  implementing  this  system,  the  introduction  of  logging  and  check 
digits  would  both  be  done.  The  computation  of  a  check  digit  is  a  trivial  addition  which 
adds  one  further  way  to  assure  that  back  tracking  is  possible  and  the  transaction  logging 
can  be  done  by  either  of  the  proposed  TT/VR  systems. 
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